Skip to contentSkip to conversation

oe.terminal: add tmux classes

PATCH Superseded Christopher Larson 2 participants 5 messages Apr 4, 2013 – Apr 5, 2013

lore
Share & tools
lore
#0 lore raw

PATCH v2 1/1 oe.terminal: add tmux classes

From: Christopher Larson <[email protected]>

This adds two new Terminal classes. It's separated into two, so that opening a split inside a tmux window is preferred to the other terminal types, but opening a tmux session is prioritized only slightly higher than screen.

- tmuxrunning: Open a new pane in the current running tmux window. Requires that the TMUX variable be added to the env whitelist to use it.
- tmux: Open a new tmux session

---
 meta/lib/oe/terminal.py | 37 +++++++++++++++++++++++++++++++++++++
 1 file changed, 37 insertions(+)
meta/lib/oe/terminal.py +37 -0
index 4c1e318..2e23d59 100644
@@ -105,6 +105,43 @@ class Screen(Terminal):
         else:
             logger.warn(msg)
 
+class TmuxRunning(Terminal):
+    """Open a new pane in the current running tmux window"""
+    command = 'tmux split-window {command}'
+    priority = 2.75
+
+    def __init__(self, sh_cmd, title=None, env=None, d=None):
+        if not bb.utils.which(os.getenv('PATH'), 'tmux'):
+            raise UnsupportedTerminal('tmux is not installed')
+
+        if not os.getenv('TMUX'):
+            raise UnsupportedTerminal('tmux is not running')
+
+        Terminal.__init__(self, sh_cmd, title, env, d)
+
+class TmuxNewSession(Terminal):
+    """Start a new tmux session and window"""
+    command = 'tmux new -d -s devshell -n devshell {command}'
+    priority = 0.75
+
+    def __init__(self, sh_cmd, title=None, env=None, d=None):
+        if not bb.utils.which(os.getenv('PATH'), 'tmux'):
+            raise UnsupportedTerminal('tmux is not installed')
+
+        # TODO: consider using a 'devshell' session shared amongst all
+        # devshells, if it's already there, add a new window to it.
+        window_name = 'devshell-%i' % os.getpid()
+
+        self.command = 'tmux new -d -s {0} -n {0} {{command}}'.format(window_name)
+        Terminal.__init__(self, sh_cmd, title, env, d)
+
+        attach_cmd = 'tmux att -t {0}'.format(window_name)
+        msg = 'Tmux started. Please connect in another terminal with `tmux att -t {0}`'.format(window_name)
+        if d:
+            bb.event.fire(bb.event.LogExecTTY(msg, attach_cmd, 0.5, 10), d)
+        else:
+            logger.warn(msg)
+
 class Custom(Terminal):
     command = 'false' # This is a placeholder
     priority = 3
Signature · 1 line
1.8.2
#1 lore raw

PATCH v3 1/1 oe.terminal: add tmux classes

From: Christopher Larson <[email protected]>

This adds two new Terminal classes. It's separated into two, so that opening a split inside a tmux window is preferred to the other terminal types, but opening a tmux session is prioritized only slightly higher than screen.

- tmuxrunning: Open a new pane in the current running tmux window. Requires that the TMUX variable be added to the env whitelist to use it.
- tmux: Open a new tmux session

---
 meta/lib/oe/terminal.py | 38 ++++++++++++++++++++++++++++++++++++++
 1 file changed, 38 insertions(+)
meta/lib/oe/terminal.py +38 -0
index 2e23d59..e52863f 100644
@@ -142,6 +142,44 @@ class TmuxNewSession(Terminal):
         else:
             logger.warn(msg)
 
+class TmuxRunning(Terminal):
+    """Open a new pane in the current running tmux window"""
+    name = 'tmux-running'
+    command = 'tmux split-window {command}'
+    priority = 2.75
+
+    def __init__(self, sh_cmd, title=None, env=None, d=None):
+        if not bb.utils.which(os.getenv('PATH'), 'tmux'):
+            raise UnsupportedTerminal('tmux is not installed')
+
+        if not os.getenv('TMUX'):
+            raise UnsupportedTerminal('tmux is not running')
+
+        Terminal.__init__(self, sh_cmd, title, env, d)
+
+class Tmux(Terminal):
+    """Start a new tmux session and window"""
+    command = 'tmux new -d -s devshell -n devshell {command}'
+    priority = 0.75
+
+    def __init__(self, sh_cmd, title=None, env=None, d=None):
+        if not bb.utils.which(os.getenv('PATH'), 'tmux'):
+            raise UnsupportedTerminal('tmux is not installed')
+
+        # TODO: consider using a 'devshell' session shared amongst all
+        # devshells, if it's already there, add a new window to it.
+        window_name = 'devshell-%i' % os.getpid()
+
+        self.command = 'tmux new -d -s {0} -n {0} {{command}}'.format(window_name)
+        Terminal.__init__(self, sh_cmd, title, env, d)
+
+        attach_cmd = 'tmux att -t {0}'.format(window_name)
+        msg = 'Tmux started. Please connect in another terminal with `tmux att -t {0}`'.format(window_name)
+        if d:
+            bb.event.fire(bb.event.LogExecTTY(msg, attach_cmd, 0.5, 10), d)
+        else:
+            logger.warn(msg)
+
 class Custom(Terminal):
     command = 'false' # This is a placeholder
     priority = 3
Signature · 1 line
1.8.2
#2 lore raw
Quoted 27 lines · Christopher Larson

From: Christopher Larson <[email protected]>

This adds two new Terminal classes. It's separated into two, so that opening a split inside a tmux window is preferred to the other terminal types, but opening a tmux session is prioritized only slightly higher than screen.

- tmuxrunning: Open a new pane in the current running tmux window. Requires that the TMUX variable be added to the env whitelist to use it.
- tmux: Open a new tmux session

---
 meta/lib/oe/terminal.py | 38 ++++++++++++++++++++++++++++++++++++++
 1 file changed, 38 insertions(+)
meta/lib/oe/terminal.py +4 -0
index 2e23d59..e52863f 100644
@@ -142,6 +142,44 @@ class TmuxNewSession(Terminal):
         else:
             logger.warn(msg)
 
+class TmuxRunning(Terminal):
+    """Open a new pane in the current running tmux window"""
+    name = 'tmux-running'
+    command = 'tmux split-window {command}'

meta/lib/oe/terminal.py class TmuxNewSession(Terminal): · line 158

Quoted 10 lines
meta/lib/oe/terminal.py +10 -0
+    priority = 2.75
+
+    def __init__(self, sh_cmd, title=None, env=None, d=None):
+        if not bb.utils.which(os.getenv('PATH'), 'tmux'):
+            raise UnsupportedTerminal('tmux is not installed')
+
+        if not os.getenv('TMUX'):
+            raise UnsupportedTerminal('tmux is not running')
+
+        Terminal.__init__(self, sh_cmd, title, env, d)

When we chatted yesterday I didn't fully understand how the Tmux Running piece worked. Now I get it, you run tmux and then start a build with in that session and just join back to it when the TMUX var is set because that is how TMUX does internal communications setup. I have to admit that is pretty slick. :-)

It seems to me we can just fold these two classes together and drive it off the TMUX variable. This way we can just have one OE TERMINAL type, and if you don't want the behavior to engage of the "split" you just unset TMUX before you build. I believe that this covers all the cases you care about, and would allow for the simplistic case I care about where I just set OE_TERMINAL=tmux to work for both cases. I would recommend we just patch up the bitbake.conf BBHASH pieces all in one shot with this patch so their is nothing special anyone has to do to make use of this.

Would you be ok with that?

Further work that I'll probably consider doing if no one else does it first is to add tmux-native so we always have it as the fall back for getting to patch failures and such on a remote build server.

Cheers,
Jason.

Quoted 27 lines
meta/lib/oe/terminal.py +24 -0
+
+class Tmux(Terminal):
+    """Start a new tmux session and window"""
+    command = 'tmux new -d -s devshell -n devshell {command}'
+    priority = 0.75
+
+    def __init__(self, sh_cmd, title=None, env=None, d=None):
+        if not bb.utils.which(os.getenv('PATH'), 'tmux'):
+            raise UnsupportedTerminal('tmux is not installed')
+
+        # TODO: consider using a 'devshell' session shared amongst all
+        # devshells, if it's already there, add a new window to it.
+        window_name = 'devshell-%i' % os.getpid()
+
+        self.command = 'tmux new -d -s {0} -n {0} {{command}}'.format(window_name)
+        Terminal.__init__(self, sh_cmd, title, env, d)
+
+        attach_cmd = 'tmux att -t {0}'.format(window_name)
+        msg = 'Tmux started. Please connect in another terminal with `tmux att -t {0}`'.format(window_name)
+        if d:
+            bb.event.fire(bb.event.LogExecTTY(msg, attach_cmd, 0.5, 10), d)
+        else:
+            logger.warn(msg)
+
 class Custom(Terminal):
     command = 'false' # This is a placeholder
     priority = 3
#3 lore raw
Quoted 58 lines · Jason Wessel
Quoted 3 lines · Christopher Larson

From: Christopher Larson <[email protected]>

This adds two new Terminal classes. It's separated into two, so that

opening

Quoted 1 line

a split inside a tmux window is preferred to the other terminal types,

but

Quoted 3 lines

opening a tmux session is prioritized only slightly higher than screen.

- tmuxrunning: Open a new pane in the current running tmux window.

Requires

Quoted 20 lines

that the TMUX variable be added to the env whitelist to use it.
- tmux: Open a new tmux session

---
 meta/lib/oe/terminal.py | 38 ++++++++++++++++++++++++++++++++++++++
 1 file changed, 38 insertions(+)
meta/lib/oe/terminal.py +4 -0
index 2e23d59..e52863f 100644
@@ -142,6 +142,44 @@ class TmuxNewSession(Terminal):
         else:
             logger.warn(msg)
 
+class TmuxRunning(Terminal):
+    """Open a new pane in the current running tmux window"""
+    name = 'tmux-running'
+    command = 'tmux split-window {command}'

meta/lib/oe/terminal.py class TmuxNewSession(Terminal): · line 158

Quoted 10 lines
meta/lib/oe/terminal.py +10 -0
+    priority = 2.75
+
+    def __init__(self, sh_cmd, title=None, env=None, d=None):
+        if not bb.utils.which(os.getenv('PATH'), 'tmux'):
+            raise UnsupportedTerminal('tmux is not installed')
+
+        if not os.getenv('TMUX'):
+            raise UnsupportedTerminal('tmux is not running')
+
+        Terminal.__init__(self, sh_cmd, title, env, d)

When we chatted yesterday I didn't fully understand how the Tmux Running
piece worked. Now I get it, you run tmux and then start a build with in
that session and just join back to it when the TMUX var is set because that is how TMUX does internal communications setup. I have to admit that is pretty slick. :-)

It seems to me we can just fold these two classes together and drive it
off the TMUX variable. This way we can just have one OE TERMINAL type,
and if you don't want the behavior to engage of the "split" you just unset
TMUX before you build. I believe that this covers all the cases you care
about, and would allow for the simplistic case I care about where I just set OE_TERMINAL=tmux to work for both cases. I would recommend we just patch up the bitbake.conf BBHASH pieces all in one shot with this patch so their is nothing special anyone has to do to make use of this.

Quoted 5 lines

Would you be ok with that?

Further work that I'll probably consider doing if no one else does it first is to add tmux-native so we always have it as the fall back for getting to patch failures and such on a remote build server.

The problem with combining them is they'd be stuck at the same priority, which makes 'auto' less useful. In the case where DISPLAY and TMUX are both set, I think it makes more sense to prefer to interact with the running tmux session rather than spawning a new xterm, yet spawning a new tmux session should be kept at the same priority as screen to meet user expectations.

A decent compromise, to make the explicit OE_TERMINAL=tmux case more useful, would be to merge the tmuxrunning bits into tmux, but still keep the independent tmuxrunning class for the 'auto' case. Thoughts on that?

Signature · 1 line
Christopher Larson
#4 lore raw
Quoted 47 lines · Chris Larson

On Fri, Apr 5, 2013 at 6:55 AM, Jason Wessel <[email protected] <mailto:[email protected]>> wrote:

On 04/04/2013 07:44 PM, Christopher Larson wrote:
> From: Christopher Larson <[email protected] <mailto:[email protected]>> >
> This adds two new Terminal classes. It's separated into two, so that opening > a split inside a tmux window is preferred to the other terminal types, but
> opening a tmux session is prioritized only slightly higher than screen.
>
> - tmuxrunning: Open a new pane in the current running tmux window. Requires
> that the TMUX variable be added to the env whitelist to use it.
> - tmux: Open a new tmux session
>
> Signed-off-by: Christopher Larson <[email protected] <mailto:[email protected]>> > ---
> meta/lib/oe/terminal.py | 38 ++++++++++++++++++++++++++++++++++++++
> 1 file changed, 38 insertions(+)
>
> diff --git a/meta/lib/oe/terminal.py b/meta/lib/oe/terminal.py
> index 2e23d59..e52863f 100644
> --- a/meta/lib/oe/terminal.py
> +++ b/meta/lib/oe/terminal.py
> @@ -142,6 +142,44 @@ class TmuxNewSession(Terminal):
> else:
> logger.warn(msg)
>
> +class TmuxRunning(Terminal):
> + """Open a new pane in the current running tmux window"""
> + name = 'tmux-running'
> + command = 'tmux split-window {command}'
> + priority = 2.75
> +
> + def __init__(self, sh_cmd, title=None, env=None, d=None):
> + if not bb.utils.which(os.getenv('PATH'), 'tmux'):
> + raise UnsupportedTerminal('tmux is not installed')
> +
> + if not os.getenv('TMUX'):
> + raise UnsupportedTerminal('tmux is not running')
> +
> + Terminal.__init__(self, sh_cmd, title, env, d)

When we chatted yesterday I didn't fully understand how the Tmux Running piece worked. Now I get it, you run tmux and then start a build with in that session and just join back to it when the TMUX var is set because that is how TMUX does internal communications setup. I have to admit that is pretty slick. :-)

It seems to me we can just fold these two classes together and drive it off the TMUX variable. This way we can just have one OE TERMINAL type, and if you don't want the behavior to engage of the "split" you just unset TMUX before you build. I believe that this covers all the cases you care about, and would allow for the simplistic case I care about where I just set OE_TERMINAL=tmux to work for both cases. I would recommend we just patch up the bitbake.conf BBHASH pieces all in one shot with this patch so their is nothing special anyone has to do to make use of this.

Quoted 8 lines

Would you be ok with that?

Further work that I'll probably consider doing if no one else does it first is to add tmux-native so we always have it as the fall back for getting to patch failures and such on a remote build server.

The problem with combining them is they'd be stuck at the same priority, which makes 'auto' less useful. In the case where DISPLAY and TMUX are both set, I think it makes more sense to prefer to interact with the running tmux session rather than spawning a new xterm, yet spawning a new tmux session should be kept at the same priority as screen to meet user expectations.

A decent compromise, to make the explicit OE_TERMINAL=tmux case more useful, would be to merge the tmuxrunning bits into tmux, but still keep the independent tmuxrunning class for the 'auto' case. Thoughts on that?

Based on how the auto list processing works your latest proposed solution seems like the most reasonable choice.

Thanks,
Jason.